Our JavaScript can be used to funnel entrances and page visitors without the need for redirect links. However, the two can and SHOULD be used in tandem.
In other words, its best that our JS is always on pages, no matter the scenario.
This is because the JS not only tracks page visits, but has several helper functions that improve the reliability of tracking.
Our JavaScript details are already documented here, which explains how to obtain data from the JS and the helper functions.
However, I will give a technical summary below.
JavaScript View Tracking
Our JS will digest the embedded attributes + URL parameters, which take priority if present, and POST a payload of data to our edge (via the user's custom domain):
https://USER_DOMAIN/js/funnel
Our edge will respond, if tracking was successful, with a standard payload that includes the visitor's ID (a VID), current node ID, and a hit ID, e.g.
{
"error": "",
"resolvedTokens": {
"{hit}": "1wj7y5680dz26p1g9p0101",
"{visitor}": "afdwb7QPV6Y59aTP3fQxZ3tX2ox",
"{current-node-id}": "0XJbzUwQYEWa"
},
"skv": "vid"
}The visitor ID is a session-level identifier of a user. These session objects are stored in a centralised cache that is deployed in multiple datacentres alongside our edge.
The VIDs have that edge location encoded into the ID, such that if users have a VID value present and change locations (or e.g. VPN), our edge can check the correct cache DB for the session object.
The Hit ID is a unique ID for the current page view. A single visitor will make a unique hit ID for every node they touch.
Current node ID is self-explanatory.
Embedded Attributes and Options
For modifying the behaviour of the FunnelFlux JS and tokens returned, please see the respective document in our JS section here.
Helper Functions
These are detailed here.
This is why its important for our JS to be present on all pages.
Firstly, The JS will automatically add a meta referrer tag to the page, which overrides the browser default behaviour and passes full referrer to onward links.
This makes the earlier urlRewrite useful, else the referrer passed by default (in Chrome at least) is hostname only
Secondly, <a> elements on the page are scanned for *action/* and if found, our JS will append:
...vid=VISITOR_ID&rn=CURRENT_NODE_ID
This explicit declaration in the action link removes any reliance on referrer/cookies in a subsequent click as the user's session identifier AND the referring node ID are declared.
Note here that the urlRewrite function adds n=CURRENT_NODE_ID to the URL, whereas action links have the current node ID added as the "rn" or "referring node" parameter.
This is important due to our other functionality: if the attribute data-lum="action" is added to any <a> element, we also append the above data.
This is useful for when direct linking between pages without an action (redirection) link, but where a user still wants to ensure reliable tracking. An example of this can be seen on the funnelflux.com homepage. Note the source code and how the link to the cloud option will update to include these URL params.
In this scenario, passing n=CURRENT_NODE_ID would load the next page, the JS would load, and the URL parameter would try to override the current page's node ID with that of the previous node, causing issues. Hence why "rn" is always used to reference the originating node in an action link.